I noticed @MichaelRoytman's PR uses the UserData object here. Do you think we should use that? The LMS can look it up but it might be nice to match how other events are sending user id / email / etc

Looking at the parameters of the downstream functions, it looks like most of them take user_id as a parameter anyways, so I think user_id is the way to go here.

Also I believe Michael's PR just has placeholder data for now.

I think it would make sense to use the UserData. It seems to be more common to use that than a user_id. But I do see uses of both, so there's precedence to use both.

I don't think we have to model our events off the way they're being consumed now. Ideally, they shouldn't be so context aware. I think, for me, it's less, "the Instructor Service currently only expects a user_id so that's what we should put in the event" and more "how can I best and most generically represent the concept of a user in my event"?

Is sending PII when we don't need to a consideration?

I think there's a good chance future downstream logic would use the pii. This probably gets hooked up to name affirmation at some point.

Some high-level questions:

1. Does the platform have other types of "exams" that would not trigger these events? If so, how do we differentiate? Note that an event is defined by its event trigger + event data.
2. For the exams covered by these events, are there multiple exam types? Would it be useful to know that as part of the event data?
3. If there are different exam types, do some of these events only apply to certain types of exam types? If so, would that be useful to note?

1. kind of. The existing exam system (edx-proctoring) does not trigger these events, the service that emits these is intended to replacement. There are no other types of exams outside that.
2. Good point. There are multiple exam types and edx-platform is mostly unaware of this since all the state/ui flows are manage by the exams/proctoring service. That said, I think there is value including this. Consumers may likely care if an exam is proctored or not. We might have actually missed a need for this. I think Credits depend on if an exam is proctored.
3. Yup some of these events are impossible depending on the exam type. A timed exam cannot be rejected since there is no video review to reject for example. We should add those details to the event descriptions

Are there non-timed exams, and are those included in this as well? Or are these just timed-exams, proctored and not-proctored? Just curious.

🤔 I guess this doesn't include 'all' exams just 'special exams' which have a different UX and workflow. Right now, all special exam types are a subset of timed. This wouldn't include normal sections instructors are using as or are graded as exams however. We could possibly reintroduce the term 'special exam' for these events which could clear this up.

If you think of this more as an API discussion around exams and special-exams, who do you think should be a part of this discussion? Maybe https://openedx.atlassian.net/wiki/spaces/COMM/pages/3554214289/Arch+Coordination+-+How+to+announce+and+tune-in will help you get the right discussion going?

^ I think this is a good idea to have before we merge. I could see people getting confused on two points

1. these events only pertain to 'special' exams
2. these events are not published by the existing exams system

I've made the following changes to address this:

• Changed the data name to "SpecialExamAttemptData"
• Added a comment about how events using this data are only emitted for special exams from the newer exams backend, edx-exams

That's better! Thank you folks.

I don't want to push hard on this, because it's not my domain of expertise, but the naming difference between EXAM_ATTEMPT_SUBMITTED and SpecialExamAttemptData just catches my attention. The obvious other option is to rename to SPECIAL_EXAM_ATTEMPT_SUBMITTED , and I guess the question I have is around the pros/cons of going with the more specific name.

🤔 🤔 It's a good question, I'd almost lean towards not using 'special' in the name at all and just commenting to the meaning? Otherwise, we need to consistently use the term across Open edX. I don't think 'special exam' has any additional meaning to anyone working outside this domain unless it's described. There was a actually discussion a while back that we stop using this term because it's just confusing, trying to dig that up.

I'm not sure how to best describe the fact that this intends to include all content that is treated with an exam user experience, but not content that might be titled (on the section or grading policy) by course teams as 'exam'. The latter is ultimately no different from other content, the platform doesn't do anything functionally different. (hence not special)

I don't think this is a decision that impacts this events library and is better explained in detail by the ADR you already linked above.

I think we can flip our focus here to be less about edx-exams and more how these events impact edx-platform. Maybe

• exam events will be consumed by edx-platform to handle all behavior as it pertains to the state of an exam subsection.
• the edx-exams service will produce these events
• there is no plan to have edx-proctoring produce these events

I think the context section might be a good place to explain the meaning of exam / special exam.

Rough points to hit

• course subsections with an exam_type have additional logic that governs completion, grading, credit requirements, and more based on the type of exam.
• these sections are sometimes referred to as special exams
• course subsections without an exam type configured may still have a grading policy named 'Exam'. This type of content does not have the exam user experience and is not governed by any exam specific logic.